Can you see a slide rather than something else? Cool. OK so I'm Tom Crane. I'm technology director of Digerati and we've been building a manifest editor. Now that's something that already exists surely, and there are lots of tools out there that allow you to construct your belief. Things, there's lots of precedent here. A lot of precedent from from us. We've been doing this kind of stuff for quite a few years, and there are some fantastic. Tools out there like annotate and exhibit that do kind of related things, so I'm just going to look at some precedent from us, plus the body and editor. I'm not going to look at any other precedent because there's just so much fantastic stuff that we could talk for hours about it. So yeah, so we've been building kind of things that make manifests for various purposes for a long time, and the broadly in editor is a thing that makes manifests for general purposes. That is a kind of venerable piece of software that's been around for a long time. So what we wanted to do was, can we build something that allows people to build presentation 3 up-to-date, IIIF manifests and also can replace the various kind of ad hoc or bespoke tools?

That we've been building over the years that that build. What are essentially manifest with annotations but that are designed to drive bespoke user experiences? And you know, we've done a few of these. We built a manifest editor a few years ago for the DNA and the Delft University of Technology that allowed the construction of of slide shows and enhance the manifest with custom behaviors to determine how transitions occurred or the placement of particular panels. The same manifest editor as the basis of work for Delft University of Technology that allowed much more complex kind of exhibition construction, including multiple kind of collage. These canvases with multiple images on them and complex layouts. Umm? These things though required. Lots of work every time you wanted to add new features because they needed their own kind of preview environments. They needed to configuration to customize the user interface and it was a lot of work to maintain a manifest editor that kind of required all this stuff when you wanted to do extra things. And you know this idea of annotation driven storytelling on top of manifests. You know that's been around for a long time. This is something we did six years ago for for welcome library.

Yeah, that includes nice triangular annotations that you can rotate to look at different builds, bits of a quilt. So these are all background use cases. We did some user research to see if we could kind of understand the different needs of people who want to create manifest and see if there was, you know, possible to produce a tool that could do. All these things. So here's our user research process. We started by gathering everything we did know and we had a kind of preliminary product strategy where we just tried to identify what is the vision of the thing we're trying to do, or our objectives. Who are our users? What would success for those users mean? What would it look like? What problems are they trying to solve and you know from our users, some of whom were real and some of whom were kind of ideal. We recruited a pool of users for testing. And then we and then we kind of went back and created a better product catalog product. The backlog prioritized that we could begin to action rather than just be kind of stories.

I went through a design process involving mixture of wireframes and technical design and kind of actual test implementations using bootstrap JavaScript to test out particular user interface ideas, and then we have the last few weeks we've been iteratively building the manifest editor, and we're kind of. Maybe number of reasons we're not, you know, we're nowhere near finished, but it's coming along and I will show you in a in a in a bit. So yeah, as I said, kind of use a mixture of wireframing and a kind of narrative based user story where the the user story is kind of a detailed user journey that's then annotated with technical details and GitHub issues. And then you know bootstrap prototypes like this one. You can see in the bottom here. So what was the product vision we came up with? There is a link to it. I'll share the links to all these slides at the end, but there is a link to the product vision here. But just to summarize it, you know the fact that most manifests of published by automated workflows, you know there are hundreds of millions of manifests in the world, probably billions by now. Most of them are made by machines, their data transformations, other sources. But you know the kind of practical, practical IIIF ability to handcraft manifests you know opens up lots of applications for research and scholarship. We heard lots of user stories about kind of remixing and extracting combining different, many different existing manifests into new manifests, deconstructing very large manifests into smaller manifests, creating these digital experiences for spoke content for digital user experiences and exhibitions. Now our users, you know, this.

Ideally, this tool should be useful no matter what your expertise in IIIF is. If you're a IIIF expert. There's no kind of problem with hand editing it in a text editor. You might want to use this tool as an alternative to doing that, just because it's nicer if you're attending a IIIF training course and learning all about IIIF. If this tool should be something that actually helps you understand what what it is you know the use of the tool should help you understand how IIIF works. And if you don't care what your life is and never want to learn anything about it, but have been given, say, a content creation task to produce a manifest, the tool should be usable without having you know, having to buy into anything you know you don't have to understand how PowerPoint file works under the hood to make a slide deck. You know that that audience is a significant audience too. So I'm going to jump in and show you some stuff now. The current UI of this is kind of preliminary, so it's not. It's not it's finished polished version. If I just jumped into the manifest additional, I've never seen it for the first time. I'd get a splash screen. That kind of just gives me a little bit of text about or in or in orienting myself, but I could just jump in and start creating stuff, but I'm going to open a manifest.

And that obscured by the zoom stuff. Of course, that did, so just just to start off with. I'm just gonna go and open and manifest that I've found or been given. I'm being warned that my Internet connection is unstable, so I don't know if I'm phasing in and out here sounds alright. OK, if if you need me to repeat anything, wave at me and I'll try and. OK thanks. OK alright so I'm just going to go and load this manifest and you can see it kind of works. It's it's viewer like I've got thumbnails. I I've got the manifest details. I've got different views. I could go into, maybe a more kind of PowerPoint style view where there's a central canvas where I've got my deep zoom capability, but I've got a thumbnail stripped down the side. Or I could go into that kind of grid view where I can even kind of rearrange things and drag canvases around and reorder things. Or I could go into an outline view and this was interesting from the point of view of learning about the kind of ideas here.

Maybe for more technical users who who would want to be interested, be interested in seeing this kind of aspect of it. You know if you open a big project in a in a in a code editor, you might see lots of structure. So the same thing here I can dive in and start looking at the canvases. As I dive down into these things, you know the the kind of contextual thing that would edit that property is available to me on the right hand side. Suspect that many users wouldn't want this kind of view, so they'd be happier with this kind of view. But let's kind of keep it. Keep our options open for different different users. And it's going to close this and start a new manifest. Where's my window? Let's go. OK, let's just go and open. We've been this right. But we still here have.

I still got Internet. OK, right? So one thing we wanted to do with this is to really be as flexible as possible for what the user might be trying to do or think they're trying to do. So I've got some examples here. So supposing I want to add a canvas now I've just gone and grabbed some test images here for what to make this easier. So here is an image that's on the on the web. And I put this in here. Now we imagine that unlike PowerPoint, if you're creating a canvas, you're probably going to be creating it from something rather than creating an empty space and putting things into it, which is the kind of slide model, so we've kind of gone with the assumption that all the default assumption that you're, you know your motivation is to create more things from content. So if you put an image in there, we'll measure it and say I'm going to create a canvas that's this size. Just add that one if you. Another one, if you create a say. That's true. And grab another image.

Have another one. At the canvas you know I can just I can just do things like this and I'm I'm not consciously creating canvases, I'm just kind of adding content. But if I needed to, I could, for example, place. I've lost my links, let me what, what if someone had given me image services rather than static images I can go and. Add chemises from them too. The same dialogue. I don't have to think about what I'm doing. Here I'm you know I've pasted an image service URL with analysed URL identified that it's an image service, not an image, but it doesn't make any difference to the end user that can just create content from it. I might also decide I'm a kind of advanced user and I said no. Actually I do want to make an empty canvas. I really do want something that's more like a PowerPoint slide that I can. I can go and put content on and I could create a canvas that way, but I'm not going to do that in this session there was just. I don't know what this to make it.

More interesting. This one. OK, so one more one more image. OK, so here's my here's my hit. So yeah, I'm generating a manifest and I'm at this point. I'm thinking what does is actually look like. I could go and preview it in Merida. What does it look like in meridale? OK, it's coming along. It's looking alright. Getting some weird labels down here but but it's working. I can preview stuff OK, so now I did notice in the mirador that my name is not particularly friendly, so let's try and improve that. What's this?

OK great great. Table now. Again, another kind of balance between the the complexity of the structure of relief and the kind of simplicity of user interface is in dealing with strings. There are lots of strings that users need to enter when they create manifest. Most of the time you're going to have. I'm thinking about a label and I'm gonna put it in there. But Chipper Leaf actually requires you to state what language your strings are and also allows you to have multiple values for those strings. So in this scenario, you know I've just gone and done this, and if I preview again, hopefully. Meredosia now has webinar, but what if? There were actually several strings I needed to put in here. I can go in and create some new ones so I can say that I can say hello and say this is in French. For example, all these things are configurable, so the dropdowns the languages available. You can add new ones, etcetera.

I can even add multiple languages in the multiple values in the same language. And so on and so on and so on. So you know, and then these get hidden behind these. These more complex things like always see that there are actually three values for this. Similarly with the kind of metadata. We try to keep it as low. Yeah, kind of low complexity as possible. But the ability to edit multiple complex language maps is still there behind the scenes. I can move these around if I want to change the order, do another preview. OK, now we've got Hello Tank webinar and we've got some metadata. One of those things didn't come out, and so yeah, so this is called now. You might have been wondering how am I managing to preview these things so one of the one of the kind of problems with hosted manifest editors that are just kind of sitting there on the web is what do you do with the stuff you creating it? Where do you put it?

So what we've done is create a very lightweight service that runs which is not a requirement for the manifest editor, but it's just a kind of useful side thing which will just host. The manifest you create as kind of as links and there are preview links and there are permit links, so I could actually save this thing to a more permanent location. This this isn't it's permanent location yet. This is a test one and you can see here it's just going to grab this if I go and open this here is here is my manifest. It's on the web. I could share that it'll stay there for a long time. Not saying this is digital preservation but it will. It will stay there for a while. And this this is an example of integrating the manifest editor with a a service for the persistence of IIIF. so, that you know out of the box it's integrated with this. Just kind of lightweight hosting service. But but you could. You could replace that with your own endpoints so that you can hook it into your own systems.

One thing I might want to do is use this manifest I'm creating in a presentation to environment. The manifest I'm creating here is presentation three. This is a presentation 3 manifest. But supposing I needed a presentation to an environment, I can export this thing as presentation two. I get a little warning saying you might lose something if you do this, but I can. I can take a presentation 2 versions away from this tool. Just going to go back to the slides for a second. I can find them. Where are they? There they go oops? Right yeah so. That's a kind of brief view of the tool itself. It's going to look at some more use cases.

Because the kind of wider use cases are, you know, assembling manifests from multiple media sources, not just images, and then this integration requirement that a manifested itself on its own, is kind of handy, but you need to be able to plug it so that things like the the file open menu or the save menu or the preview menu, or the browse to import menu can all have configurable endpoints, so you could hook them into into your own systems. We want to be able to create manifest kind of completely interoperable, but also at the same time. Drive custom viewing experiences. So again, the config. You know the behaviours that are available to you out of the box are standard IIIF ones, but you could configure additional behaviours that are available in your environment to to to drive whatever extra functionality you need now. One difference between this tool and maybe a bodily manifest editor is the kind of how far do we go with annotations on canvases. If you want to meet some of those use cases that we saw for Delft, we actually need to be able to position. Media at different places on the same canvas and we need to be able to draw boxes and annotate the canvas with labels and descriptions and text and HTML. Support advanced composition features and colleges. So these are all kind of feature things which are in in the GitHub issues, but aren't in the preview yet. Yeah, so and then this other this other kind of consideration came up because as we were gathering the use cases, some of these many of the use cases were not specifically about editing manifests. As in here is 1 manifest in the tool that you are adding things to or you know creating from scratch. They were about reorganizing existing manifests, cutting them up.

They were about building IIIF collections rather than manifests as well. They're about using kind of specific tooling in a leaf context that isn't actually manifest editing or isn't visual. Things like you know bulk tools for pagination and things like that now. These are all considerations and I'll get to the kind of implications of some of them in a minute. But our biggest consideration is about persistence. It's this kind of idea that. A IIIF manifest if you approach it thinking it's going to work like a slide deck. You're going to have problems when you try to, you know, when you expect that you would be able to get images off of your desktop and like put them in the manifest. A triplite manifest is more like a web page. It's a document full of links to resources. If those resources are already there on the web, you need to add them into the manifest and make links to them if they're not already there on the web, you need to put them on the web somehow and the the place you may put one to put them may not have anything to do with where you want to put the manifest. So how do we solve that stuff? This is the kind of big problem with persistence, so we thought you know, in developing the manifest editor, we kind of shortcut a lot of that by providing an out of the box persistent solution.

For the manifest itself that demonstrates the pluggability, but we have not yet done anything to demonstrate integration with persistence of assets of images. But we want to make that pluggable too, so that if you do have images, you know desktop there's a hook in the manifest editor when you add a new canvas or add content to a canvas, you'll be able to, say, send it to that service, so I can. It can be hosted for me. Yeah, so this is this, you know this this need for infrastructure, a manifest on its own. It's no good unless you host it somewhere. But even if you managed to host the manifest somewhere, it's no good unless all the things it points out are also hosted somewhere. So it's that kind of need for infrastructure. And that kind of brings us to something that came out of the user research that we thought kind of was obvious, but actually wasn't all that obvious about what exactly we're building here. Yeah, because with all this talk about services and hosting, the manifest editor itself is an open source JavaScript application under MIT. Anyone can take it from GitHub and host it wherever they like. Do what you want with it, extend it we want to make it completely pluggable and flexible so you can adapt it and put it into existing. Tooling and workflows connect it to your content management system or repository. Umm?

But in order to, you know, for it to be useful to someone, or to have someone to kick the tires or get an understanding of what it is, it's no good. It just being a repository on GitHub, like the body in editor. It needs to be hosted somewhere and also it needs to have persistence at least of the manifest. So if you go along and play around with it and create a cool manifest from existing resources, you get a permalink you can take away and share with people and show them what you've done. And thinking about those other use cases about the kind of you know, adjacent tasks that people want to do, we've built the manifest editor as a kind of combination of a shell application with the manifest editor itself being an app that's loaded in the middle. Because the shell can provide the same services to other kinds of applications, so you know things like loading, IIIF browsing for IIIF, managing saving of IIIF, state management of resources you've loaded into the tool, and undo and redo stack previewing. These are all services that could be you know. Could be services to multiple kinds of applications, not just to kind of pure visual manifest editor, so we've kind of separated out the components of the tool into these these concepts. And I would urge anyone who's interested in this to go and look at the wiki that we've got on our on the GitHub site for this page, which kind of just just talks through the ideas about how this thing is constructed. It's architecture because we really good to hear other people's opinions on how this would be good to fit into your into your various environments. Just something I want to come back to again. We did a lot of prototyping using sort of bits of bootstrap and and wireframes as well, but thinking about this issue of. Like just not requiring the user to make any decisions that we could possibly help them make.

So anytime you bring in some content anytime there's a URL. Let's learn about as much as what's what's on the other end of that URL as we can so that you know you don't have to kind of think about what's happening there. Don't don't prevent the user from controlling that, but just fill in as much as we can. So if you think even just linking to an image or a video or something, asking someone to fill out this form. Is one thing because most of the stuff on here we could actually fill out ourselves by, you know, just interrogating what's on the other end of a link. So generally that kind of idea of of making the tool do the work, not the, not the user do the work. It is kind of central to the way it's designed. The other big challenge is. We could say we're going to stick to a certain number of features and not support UI to edit the others. But how do we know what you're gonna load into the tool? You know you could bring any manifest to the tool and we don't want to break people's manifest just because we haven't got a particular complex user interface to support the structure that they've got in their manifest. So it's kind of dealing with that. You know what's the kind of baseline where we won't break anything that people load into it, as long as it's valid, but we weren't necessarily offer a complete, wonderful visual environment for every possible life construction that you can think of.

That's a pretty tricky question to solve, so we're still working on on that one. Just a quick word just to finish off about the foundations of this tour. It's built on a library called Vault which is used for state management and loading and saving and normalization of leaf and it's built on the visual component called Canvas panel which provides the kind of viewing surface or annotation service surface for canvases. Vault is in 555 Commons and canvas panels still under development. OK, I should probably stop because I think I've taken up at least 25 minutes.